試験で使える!!Cloud SQLの基礎知識(Google Cloud)

試験で使える!!Cloud SQLの基礎知識(Google Cloud)

今回も資格試験、初級者向け用にCloud SQLを解説していきます。試験や初学者の知識として、特に求められることは「そのリソースの特徴を理解できているか」に尽きると思います(個人的に)。Cloud SQLの概要を掴み、ぜひ学習に役立ててください。
Clock Icon2023.04.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

初めに

Cloud SQLとはGoogle Cloud(旧GCP)内でMySQLPostgreSQLSQL Serverを運用できるマネージドサービスになります。
オンプレミスからの移行の選択肢としても多く採用され、機能も豊富なためRDBMS(リレーショナルデータベース管理システム)としては、まず最初に考える第一選択肢となります。

今回はその基本的な仕組みと機能について、解説していきます。

まず初めにRDBMSの簡単な解説をするので、Cloud SQLの構造から知りたい方は、左にある目次メニューからバックアップ機能を選択して、RDBMSとはを飛ばしてください。

RDBMSとは

まず初学者の方からすると、RDBMS(リレーショナルデータベース管理システム)自体、フワッとした理解だと今後の説明で分かりにくい箇所が出てきてしまう可能性があるので、おさらいをしておきましょう。

簡単に言うと、下記画像のような構造化された表形式のデータになります。(テーブルともいう)
表形式のExcelを例に出すと分かり易いかもしれません。

このような表形式のデータは構造化データとも表現され、基本的にSQL文を使用してクエリを投げることが可能です。(投げる=検索,消す,更新する..etc)
SQL文を知らない方からすると、意味不明かもしれませんが、このようなテーブル形式のデータは1つだけではない事が多いです。
色々な表形式のデータが連なって、大きなデータベースとして存在しています。

そうなった場合に、何十何百ある表データを目視で見ていて目が10個あっても足りません。
そこでSELECT * FROM usersのようなSQLを表データがまとまったデータベースなどに、クエリとして検索を投げると、その検索結果に沿った形で新しいテーブルが作成され、見たかったデータを作ることができるのです。(SELECT以外にも、テーブルを消したりアップデートしたりするコマンドが存在します)

RDBMSとSQL文の解説はこの辺にして、次からCloud SQLの機能について触れていきたいと思います。
まだピンときていない方はいくつかのサイトの情報をかけ合わせて理解すると、より深く知ることができるのではないかなと思います。
RDBMSとはSQL文とは、でググれば参考になるサイトが山ほどあるので色々と見てみてください)

まとめ

・Cloud SQLはRDBMSの構造化されたデータの管理/活用に最適

・表データにクエリ(SELECT * FROM users...など)を投げることで様々な操作が可能

・クエリは複数のテーブルがまとまったDBに対して投げる事が多い

バックアップ機能

まずはデータを守るために不可欠なバックアップ方法について解説していきます。

2種類のバックアップ

バックアップとは何らかの障害などによりデータが紛失した時などに有用に使え、簡単に言うとある時点のデータの状態を保存しておくことになります。

オンデマンドバックアップ

オンデマンドは次に紹介する自動バックアップとは逆に手動でバックアップを作成する方式です。
シチュエーションとして、データベース上でリスクの高いオペレーション(操作)を実行しようとしている場合や、自動バックアップで設定した時間枠に関係なくバックアップを作成したい場合などになります。
また、先にお伝えした通り、自動バックアップを有効にして、随時オンデマンドでバックアップするといった併用が可能です。

また、自動的に削除などはされないため、手動で削除するか、インスタンスが削除された時に一緒に削除されます。

自動バックアップ

指定した〜4時間の枠の中で毎日バックアップが行われます。指定したバックアップ時間枠内(〜4時間以内)に開始されます。こちらは、インスタンスの使用率が最も少ない時間帯にバックアップを実行することが推奨されています。

また、インスタンスが停止した場合にも追加の自動バックアップが作成され、停止する前のすべての変更が保存されます。
デフォルトでは、最新の7件のバックアップが保持されます。インスタンスが36時間以上停止されている場合、自動バックアップは停止されます。
デフォルトからのバックアップ数の変更は、1~365の範囲指定することが出来ます。

バックアップの保存場所

バックアップの場所を指定しない(デフォルト)場合にはデフォルトの保存場所として、Cloud SQLインスタンより最も近いマルチリージョンのロケーションで保存されます。

【参考】

たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。

【補足】
・usマルチリージョンに該当する場合のみ
画像では世界中のリージョンに保存されているように見えますが、実際のバックアップ先はusマルチリージョンに該当するリージョンのみになります。

・カスタムロケーションで任意の場所を選択可能
このシュチュエーションとしては、リージョンの選択は国単位となるので会社ごとに決められたデータを扱うポリシーの遵守が必要な場合に、任意の場所を指定する事があります。
このような場合、その会社の組織に組織ポリシーとしてあらかじめ制限することで予期せぬポリシー違反を防ぐ事が可能です。
詳しくは、リソース ロケーションの制限をご覧ください。

まとめ

・オンデマンドバックアップは手動

・自動バックアップは毎日4時間以内の範囲で、定期的に行なってくれる

・バックアップデータは1~365個の範囲で保存可能

・バックアップデータの保存場所はデフォルトリージョン or カスタムリージョンから選択できる

HA構成(高可用性/フェイルオーバー)

Cloud SQLはリージョンリソースと呼ばれ、各ゾーンごとに分散が可能です。
対照的に、グローバルリソースというのはリージョンを跨いだ分散配置が可能となる使用です。(Cloud Spannerなど)
資格試験などではこの辺の理解も必須になってくるので、ある程度は覚えておいた方が解きやすくなると思います。

高可用性

Cloud SQLにはHA構成という仕組みがあり、リージョン内のゾーン単位でデータを保持しておくことで冗長性の確保が可能となります。
作成したインスタンスが稼働するゾーンをプライマリゾーン、そのインスタンスはプライマリインスタンスと呼びます。
さらに、HA構成で追加されている方のゾーンをセカンダリゾーン、そのインスタンスはスタンバイインスタンスと呼びます。

つまり、高可用性 = 災害時の復旧のための構成、と言い換えることも出来ます。

フェイルオーバー

インスタンスやゾーンに障害が発生した場合、スタンバイインスタンス → プライマリインスタンスに昇格させます。ユーザーは新しいプライマリインスタンスに再転送され、引き続きサービスを使うことが可能です。これを総じてフェイルオーバーと呼びます。

仕組みとしては、HA構成された各ゾーンの永続ディスクへの同期レプリケーションにより、プライマリインスタンスへの書き込みのすべてが両方のゾーンのディスクに複製されることにより、障害時のフェイルオーバーが可能となります。
このディスク自体はリージョン永続ディスクと呼ばれたりします。

また、フェイルオーバー後の動きとしては、プライマリに昇格したインスタンスはそのまま使用され、障害が起きたインスタンスは再作成されます。
フェイルオーバーが発生した時のダウンタイムはおよそ3分ほどのようです。

HA構成とフェールオーバーをまとめた図を載せます。

【補足】
・障害が発生した元のプライマリを使用したい場合にはフェイルバックが可能です。
手順については左記をご覧ください → フェイルオーバーを開始する
・トラフィックはセカンダリインスタンスのとなっても同一のIPでアクセスを振り分けることが可能です。

リードレプリカ

Cloud SQLにはリードレプリカという読み取り専用のインスタンスを作成することが可能となります。
いくつか使い方がありますが、基本的には名前の通りプライマリDBの負荷を軽減する役割を持ちます。
もちろん、プライマリDBには書き込みが発生するので、障害が発生した場合にはサービスに影響があります。
リードレプリカは単にプライマリのデータを複製したものになりますので、ユーザー側のDB読み取り複数または単一のリードレプリカに分散させることで、プライマリ負荷の軽減の他に、高可用性も確保することが可能となります。

HA構成の料金に注意

スタンドアロン型(1つのインスタンスのみ)の場合と比べて、2倍の費用が掛かってしまいます。料金が発生するリソースとしてはCPURAM、およびストレージの料金が含まれます。
(参考:料金のページ)。

まとめ

・HA構成とは可用性と障害復旧のための仕組み

・複数のゾーン単位でセカンダリレプリカを配置することが出来る

・フェイルオーバー後はセカンダリがプライマリを引き継ぐ(戻すことも可能)

・リードレプリカでプライマリの負荷を軽減 & 高可用性も確保出来る

・HA構成では料金は2倍かかる

Cloud SQLへの接続

ネットワーク周りの仕組みを頭に入れておくことは試験には必須の知識であり、Cloud SQL自体を理解する上ではとても重要なものです。
教科書で最初に学んだ時につまずく点としては、自分のVPCの中に作成して運用するのか?という点だと思います。
結論から言うと、Google管理のVPC内に外部IPを利用してアクセスすることになります。

私の覚え方としては、そもそもPaaSというマネージドサービスの位置付けのためGoogle管理のVPCで作成されるんだな~ ←このように理解し暗記しました(あくまで覚え方)
次から具体的な接続方法について解説していきます。

外部IPを利用したアクセス

インスタンスのセキュリティを保つため、基本的には重要なリソースには外部IPは付与したくありません(セキュティ攻撃を受ける穴になり得るから)。
ただし用件や環境などによって、パブリックIPをSQLインスタンスに付与する場合には、Cloud SQL Auth Proxyまたは承認済みネットワークのどちらかを使用して認可する必要があります。

このシュチュエーションとして考えられるのは、VPCの要件(ピアリングなどができない)を満たしていないクライアントから接続する場合は、外部IPを使用してインスタンスを構成する場合があります。
よって、当たり前かも知れませんが、次に紹介するピアリングでの接続外部IPでの接続の併用は可能となります。

また今回は割愛しますがMySQLクライアントを使用して接続する方法もありますので、そちらはURLをご覧ください。

Cloud SQL Auth Proxyについては後ほど詳しく解説するので、ここでは承認されたネットワークについて触れましょう。

とはいいましてもその言葉通りの意味で、インスタンスが持つ外部IPアドレスへの接続は、承認済みネットワークから送信された場合のみ許可されます。
この承認済みネットワークとは、ユーザーが事前に接続する事を許可した、単体のIPアドレスIPアドレス範囲のことです。

Cloud SQL Auth Proxyを使用しない要件がある場合には、こちらを検討します。

Private Service Access

こちらのアクセス方法としては、プライベートIPを利用してアクセスしたい場合に便利です。
ただ先ほど言いました通り、セキュリティの観点から考えると、基本的にDBサーバーに外部IPを付与するのはあまりしたくありません(もちろん用件により異なる)。

Private Service Accessではピアリング機能を利用して、VPCとVPC間を繋ぐ役割をしてくれます。
ということは、1つの同じVPC内にいるかのようにプライベートIPを使用して他社のVPCと接続したりできるわけです(ここ意外と試験ポイントです)。

少しピアリングに話がそれてしまいましたが、セキュアに閉域な環境でCloud SQLにアクセスした場合にはPrivate Service Accessをおすすめします。

【ピアリングのイメージ図】

【補足】
・画像では他社VPCとの接続を例にしてますが、Cloud SQLの場合も同じ原理です。(Google管理のVPCとピアリングするため)

Cloud SQL Auth Proxy

IAMの認証情報を使用して接続の認証/認可を設定できます。
外部IPを利用した接続になり、最も簡単かつ便利な接続方法となります(セキュリティ的に外部IPをダメと言いましたが、なるべく基本的には、、、というスタンスです)。

ユーザー情報またはサービスアカウントの認証情報を使用して認証認可を行い、Cloud SQLインスタンスへ受信される接続をSSL/TLSラップして接続します(SSL/TLSラップはざっくり言うと通信を暗号化すること)。

よってAuth Proxyは、Cloud SQLインスタンスに通信を渡す中間サーバーとしての機能を果たします。

それぞれのリソースによっては(Cloud RunやCloud Function、AppEngineなど)、Cloud SQL Auth Proxyを使用して接続することが可能です。
詳細については、左記のURLをご確認ください → Cloud SQL Auth Proxy

まとめ

・外部IPを使用したアクセスには承認されたネットワークがある

・外部IPを使用したアクセスにはがあるCloud SQL Auth Proxyがある

・内部IPを利用してアクセスをしたい場合にはPrivate Service Accessを使用する

・Cloud SQL Auth Proxyを利用するとIAM情報を利用してセキュアに外部(社外IPなど)からアクセスが可能となる

まとめ

今回は、Cloud SQLの基本機能についてまとめました。
その他にも重要な機能がいくつか存在しますので、機会があればまた第2弾としてブログに出来ればなと思っております。
(あまり長くても最後まで読むの辛いですからね、、、笑)

ただ、試験や初学者が押さえておきたいポイントは今回の内容で結構まとまっていたりするので、ドキュメントなどを読み、これは必要だな〜と思えば再度執筆します。
まとめはそれぞれの項目の下に記載しているので、随時確認ください。?‍♂️

最後に

前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています!!IT=脳=運動=体調管理⇒全ては繋がっています。

【家での筋トレは身/脳を鍛える宝庫】

現在は宅トレ(家筋トレ)期間中なのですが、かなりメリットが大きいのではないかと、強く思います。

その理由について、下記にまとめます。

・1年以上継続するならジムよりお金が掛からない

・試行錯誤のすえ編み出した筋トレは脳を発達させる

・圧倒的な時間の節約が可能

・人がいないので気が散らない

・人がいないため休憩中に勉強できる

・家なので疲れたら猫をもふもふして、嗅げる、そして引っかかれる(元野良猫だから)

もっとありますが、とりあえずこんな感じです。

次回はデメリットを紹介します。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.